Although basic interpolation is useful, we often want to handle parameters
differently, not using the standard modification we apply to them. This commit
introduces modifiers, a concept already present in Respect\Validation.

We use a familiar `{{value|modifier}}` syntax found in many popular template
engines. To handle different types of modifiers, I implemented a Chain of
Responsibility, where each modifier delegates to the next one when it cannot
handle them.

The `StringifyModifier` remains the default fallback, ensuring that we don't
lose the robust type-handling we previously built, but I've also made some
changes to it. I realise that for Respect\Validation, we have a strong need to
add "quotes" around strings because they represent values that were just
validated, but in the context of placeholder replacement, this behaviour is
undesirable.

I've created the `AutoQuoteModifier`, which quotes scalar values by default and
provides a `|raw` pipe to bypass quoting when clean output is needed. This
allows Validation to retain its quoting behaviour while keeping the default
`PlaceholderFormatter` chain simple.

Assisted-by: OpenCode (GLM-4.6)
Assisted-by: Gemini 3 (Thinking)

I based this new modifier on the `ListAndModifier` and `ListOrModifier` from
Respect\Validation, but I wanted to improve on that design. Instead of
maintaining two separate modifiers that repeat almost identical behavior
just to change a conjunction, I’ve unified them into a single, versatile
`ListModifier`.

The power of this new approach lies in its flexibility; it allows for
configurable conjunctions directly via the pipe syntax. This allows us to
transform raw arrays into lists that actually make sense to a human reader.
Whether we need a list joined by "and," "or," we can now produce more natural
strings instead of falling back on a simple comma-separated list.

Assisted-by: OpenCode (GLM-4.6)
Assisted-by: Gemini 3 (Thinking)